…build bot

NOTE: Only considers i64 based vectors at this time because smaller
element types require extra isel operand parsing.

Differential Revision: https://reviews.llvm.org/D118040

Currently not (xor_one_use) pattern is always selected to S_XNOR irrelative od the node divergence.
This relies on further custom selection pass which converts to VALU if necessary and replaces with V_NOT_B32 ( V_XOR_B32)
on those targets which have no V_XNOR.
Current change enables the patterns which explicitly select the not (xor_one_use) to appropriate form.
We assume that xor (not) is already turned into the not (xor) by the combiner.

Reviewed By: rampitec

Differential Revision: https://reviews.llvm.org/D116270

Test on SSE2/SSE41/AVX1 targets to compare PMOVMSK vs PTEST codegen paths

Add v8i8 reduction case and test on X64 and X86 targets to check 32-bit handling

This revision adds enough support to allow InlineAsmOp to work properly with indirect memory constraints "*m".
These require an explicit "elementtype" TypeAttr on the operands to pass LLVM verification and need to be provided.

Reviewed By: bkramer

Differential Revision: https://reviews.llvm.org/D118006

A few header removal, some forward declarations. As usual, this can
break your build due to false dependencies, the most notable change are:

- "llvm/BinaryFormat/AMDGPUMetadataVerifier.h" no longer includes "llvm/BinaryFormat/MsgPackDocument.h"

The impact on generated preprocessed lines for LLVMBinaryFormat is
pretty nice:

$ clang++ -E  -Iinclude -I../llvm/include ../llvm/lib/BinaryFormat/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before this patch: 705281
after this patch: 751456

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

The demangler test harness is a little unclear.  The failed demangling
message always causes me to think about 'reality', changing to a
simple 'Found' seems clearer.

The expected-to-fail tests abort as soon as one passes, rather than
continue, and then abort if any passed.  This changes that loop to
fail at the end, in a similar manner to the expected-to-work loop.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D118130

Code generating the special substitutions in std is a switch statement
with each case block containing the same conststruction template.  It
is more efficient to commonize that after the switch, having
determined which SubKind to create.  Also, let's sort the cases.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D118131

`tco` does not generate machine code, so it does not require (machine)
code-gen related dependencies.

Differential Revision: https://reviews.llvm.org/D118112

This should be no functional change, as the cases supported by the
helper and the cases supported by DSE are currently the same, the
code structure is just slightly different.

Should fix  https://lab.llvm.org/buildbot#builders/37/builds/10259

Packed-mode broadcast of f32/i32 requires the subregister to be
replicated to the full I64 register prior. Add repl_i32 and repl_f32 to
faciliate this.

Reviewed By: kaz7

Differential Revision: https://reviews.llvm.org/D117878

Comment change only, no functional change intended.
Example of warning:
https://lab.llvm.org/buildbot/#/builders/188/builds/8696/steps/4/logs/warnings__2_

Based on the output of iwyu. A full rebuild of llvm-project doesn't exhibit any
significant false dependencies.

The impact on preprocessed output is larger than expected, given the small
amount of changes

$ clang++ -E  -Iinclude -I../llvm/include ../llvm/lib/TextAPI/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 635319
After: 643716

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

The tag map holds a sparse set of memory tags and allows
you to query ranges for tags.

Granules that do not have tags will be set to llvm::None.
to keep the ordering intact. If there are no tags for the
requested range we'll just return an empty result so that
callers don't need to check that all values are llvm::None.

This will be combined with MemoryTagManager's MakeTaggedRanges:
* MakeTaggedRanges
* Read from all those ranges
* Insert the results into the tag map
* Give the tag map to whatever needs to print tags

Which in this case will be "memory read"/DumpDataExtractor.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D112825

This commit llvm/llvm-project@75e164f removed the AutoConvert.h header causing a build break on z/OS. This patch adds it back to fix it.

Reviewed By: zibi

Differential Revision: https://reviews.llvm.org/D118129

Starting with VS 2019, CMake defaults to the x64 host toolchain, so the
warning does not apply anymore.

References:
VS 2017 defaults to x86
https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html?highlight=host#toolset-selection
VS 2019 and 2022 default to x64 for x64 targets
https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html?highlight=host#toolset-selection
https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2017%202022.html?highlight=host#toolset-selection

Differential Revision: https://reviews.llvm.org/D118228

We have some bitcasts which we know will be simplified,
so their cost is zero.

Reviewed By: david-arm, sdesmalen

Differential Revision: https://reviews.llvm.org/D118019

We could keep the non-i8 GEP code for non-opaque pointers, but
there's two reasons I'm dropping it: First, this actually appears
to be dead code, at least it isn't hit in any of our tests. I
expect that this is because we usually expand trip counts, and
those are never pointers (anymore). Second, the non-i8 GEP was
actually incorrect in multiple ways, because it used SCEV type
sizes, which don't match DL type sizes (for pointers) and certainly
don't match type alloc sizes (which is what GEPs actually use).
As such, I'm simplifying the code to always use the i8 GEP code
path if it does get hit.

This adds an option --show-tags to "memory read".

(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x0000000000000000 0x0000000000000000 (tag: 0x0)
0x900fffff7ff8010: 0x0000000000000000 0x0000000000000000 (tag: 0x1)

Tags are printed on the end of each line, if that
line has any tags associated with it. Meaning that
untagged memory output is unchanged.

Tags are printed based on the granule(s) of memory that
a line covers. So you may have lines with 1 tag, with many
tags, no tags or partially tagged lines.

In the case of partially tagged lines, untagged granules
will show "<no tag>" so that the ordering is obvious.
For example, a line that covers 2 granules where the first
is not tagged:

(lldb) memory read mte_buf-16 mte_buf+16 -l32 -f"x" --show-tags
0x900fffff7ff7ff0: 0x00000000 <...> (tags: <no tag> 0x0)

Untagged lines will just not have the "(tags: ..." at all.
Though they may be part of a larger output that does have
some tagged lines.

To do this I've extended DumpDataExtractor to also print
memory tags where it has a valid execution context and
is asked to print them.

There are no special alignment requirements, simply
use "memory read" as usual. All alignment is handled
in DumpDataExtractor.

We use MakeTaggedRanges to find all the tagged memory
in the current dump, then read all that into a MemoryTagMap.

The tag map is populated once in DumpDataExtractor and re-used
for each subsequently printed line (or recursive call of
DumpDataExtractor, which some formats do).

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D107140

AMDGPUHSAMetadataStreamer currently assumes that pointer arguments
without align attribute have ABI alignment of the pointee type.
This is incompatible with opaque pointers, but also plain incorrect:
Pointer arguments without explicit alignment have alignment 1. It is
the responsibility of the frontent to add correct align annotations.

Differential Revision: https://reviews.llvm.org/D118229

…on & hover

Underscore-uglified identifiers are used in standard library implementations to
guard against collisions with macros, and they hurt readability considerably.
(Consider `push_back(Tp_ &&__value)` vs `push_back(Tp value)`.
When we're describing an interface, the exact names of parameters are not
critical so we can drop these prefixes.

This patch adds a new PrintingPolicy flag that can applies this stripping
when recursively printing pieces of AST.
We set it in code completion/signature help, and in clangd's hover display.
All three features also do a bit of manual poking at names, so fix up those too.

Fixes clangd/clangd#736

Differential Revision: https://reviews.llvm.org/D116387

This patch replaces the exact include count of each file in `HeaderFileInfo` with a set of included files in `Preprocessor`.

The number of includes isn't a property of a header file but rather a preprocessor state. The exact number of includes is not used anywhere except statistic tracking.

Reviewed By: vsapsai

Differential Revision: https://reviews.llvm.org/D114095

Update for LLVM commit 184591a ("[OpaquePtrs] Deprecate
PointerType::getElementType()", 2022-01-25).

This commit changes all affected calls to getPointerElementType, which
is a temporary solution.  Followup work around the
getPointerElementType calls will be required to align with LLVM's
opaque pointer changes.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@7452422

So that it could be used in downstream.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@d3884d8

…translation (intel#1346)

This patch adds translation to and from `spirv.Decorations` and
`spirv.ParameterDecorations` metadata. These metadata nodes represent
global variable and function parameter decorations respectively,
allowing explicit decoration in LLVM IR.

Signed-off-by: Steffen Larsen <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@ccdbbdb

Signed-off-by: Alexey Sotkin <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@ada2fd4

Signed-off-by: Dmitry Sidorov <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@7f168b2

This is a patch to fix forward translation of VectorExtractDynamic with sret
argument of SYCL half type & fix reverse translation of VectorInsertDynamic
with component of SYCL half type by adding extra instructions.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@ea5ef3f

If there are more than one argument in DIArgList, we can't represent it in
SPIR-V with the current SPIR-V debug info spec. In this case we drop DIArgList
and DIExpression.

Signed-off-by: Alexey Sotkin <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@fb2dd0e

The upstream patch triggered assertion on most of SYCL tests:
`AST/Decl.h:275: llvm::StringRef clang::NamedDecl::getName() const: Assertion Name.isIdentifier() && "Name is not a simple identifier"' failed.`

Fix includes the following changes:
* Check that name of function exists before trying to access it.
* Make sure that host accessor doesn't have sycl_special_class attribute
* Enable diagnostics for sycl_special_class attribute only for SYCL device compilation.

The test started to pass after support for element-wise operations on joint
matrix was added to llvm-spirv.

This change adds missing docs inroduced in llorg.

…ected alignment

This is a cherry-pick of a10ff37